Size Change: +1.14 kB (0%)

Total Size: 1.4 MB

_{compressed-size-action}

Exploring...
Installed the Gutenberg PR.
Made sure to save the Navigation.
Went to the top/parent Navigation block. (Not entities inside of it.)
Clicked the 3 dot menu.
Noticed down the list a "Edit Header navigation" and selected it.

Came into focused mode.

My initial reaction is that this is a very hidden approach to adjusting the Navigation. It should be much more open approach to handling the navigation entities/elements/links. This is not a good approach to use for adjusting the navigation. As it needs to be much more visible when the Navigation block is selected.

List view
List view which is a good place as it is a current method more and more users will need to get used to to get an overview of the layout. Drilling down into blocks and adjusting the Navigation directly in List view would be an interesting approach.

Settings Sidebar.
Could also be an interesting way. As it uses the existing method of going to the sidebar settings panels to adjust aspects of a block. In this case a full Navigation drag and drop similar to the classic Navigation screen. (Could perhaps be a bit tight on the space.)

#38600 (comment)
Has a Navigation icon below the W icon. One clicks to open the Navigation.

I made a video:
https://youtu.be/qFebtfHZJLU

Thanks for taking the time to provide feedback @paaljoachim 👏 🙇‍♂️

This is not a good approach to use for adjusting the navigation

I'd like to challenge that a little. My understanding is that your argument is based on the fact that currently the focus mode is a little hard to discover. Am I right? If so, I agree with that - perhaps the same could be said of all "focus" modes (including Template Part editing).

However, just because it's hidden now, does not mean we could not easily expose a more convenient method to access it directly from the block.

The key benefits of a focus mode are:

• ability to edit the menu using the familiar direct-manipulation experience afforded by blocks
• allows access to the inner blocks of the Navigation Menu (this has been requested many times since 5.9) - note that usually these are not available because the Navigation block uses ref to fetch the items from a custom post.
• allows user to edit a menu which may not be easy to manipulate within the context of the post/page/site - for example if the menu is set to be in "hamburger" (mobile) mode that you cannot see the items to edit. Being able to drop into focus mode and make changes to the structure is highly valuable.

I appreciate this exploration is extremely rough around the edges. However, I'm keen that we don't prematurely dismiss this approach given the value I think it might afford for users.

What do you think?

List view which is a good place as it is a current method more and more users will need to get used to to get an overview of the layout

There is a good argument that a list view based approach is a good idea.

However, I'm concerned that it's not the ideal environment for direct manupulation and we're going to end up having to duplicate a lot of the functionality we get from blocks within the editor canvas (e.g. styling, text label manipulation, block attribute adjustment...etc). I fear we may bloat the list view if we tried to add all these features. To me we'd be better served to reuse the existing canvas-based block tooling we have available already. That's where the focus mode comes in.

I'll also add that I don't see focus mode and sidebar mode as being mutually exclusive (neither does @mtias). They can be complementary.

Hey Dave

I see all focus modes as hidden modes of editing (Except the create a template focus mode). The more direct visible editing we have the better. As it shows it more openly how one would go about editing.

Focus mode. Initial view.

• Takes the user away from the regular Gutenberg canvas.
• Is somewhat complementary to regular edit a block in the Gutenberg canvas.
• To me it feels like focus mode might bring in additional editing capabilities. Which can not so easily be added to the Gutenberg canvas (This feeling might be wrong.)
• I feel that focus mode could instead stay within the regular Gutenberg canvas.

(The above is my impression with a few toes in the water so to speak.)

I appreciate this exploration is extremely rough around the edges. However, I'm keen that we don't prematurely dismiss this approach given the value I think it might afford for users.

However, just because it's hidden now, does not mean we could not easily expose a more convenient method to access it directly from the block.

Good point! Improving Focus mode visibility will be helpful. My feedback is based on the experience of focus mode up til this point.

What do you think?

I think that we/I need to look at Focus mode and how we can in general improve this feature.

When adding the possibility of using List view to manipulate the Navigation. I could see in the back of my mind that List view would be too limited to all that is needed. Having a separate screen of some kind is still likely needed.

I'll also add that I don't see focus mode and sidebar mode as being mutually exclusive (#36667 (comment)). They can be complementary.

Your various comments swayed me Dave.
It seems that focus mode and a sidebar settings panel is the way to go.

This is cool! But we actually need this for every block, not just navigation. The ellipsis also feels like the right place to add this option, because it can indeed be block agnostic.

The main challenge I see there is that the ellipsis menu is already very long, and adding more options to it is tricky. I don't know if this is a blocker, but I'd love input from @jameskoster and @richtabor as well. Some questions to ponder:

• Should the label change, something "Edit isolated"? "Edit alone"? "Edit in isolation"?
• Should there be an edit icon in the menuy? Perhaps the edit-small?
• Do we need for nested menus to land first, so the ellipsis menu doesn't grow too long, or can it accommodate this one?

Thanks Dave, this is sweet stuff.

But we actually need this for every block, not just navigation.

Interesting. Bear in mind this example is designed to sync with the nav item entities. Whereas for most other blocks this would just be standard inner blocks. We could adapt it to make it more flexible though.

As I noted in #50396 (comment), this experience can be a bit strange given the Navigation styles and settings cannot be included in focus mode. Seeing a horizontal menu on the canvas which jumps to vertical orientation when I click "Edit" is surprising. It kind of suggests I'm editing something else. I know this isn't trivial to fix, but it does concern me a bit about merging this.

@jasmussen if we didn't want to clog up the ellipsis menu, we might add an "Edit" item to the toolbar, like template parts:

I agree we shouldn't be merging this as is. It's still Draft after all 😄

But...it would be good to outline some of the problems/concerns like you have done here @jameskoster. Thank you.

if we didn't want to clog up the ellipsis menu, we might add an "Edit" item to the toolbar, like template parts:

I do like that edit button. But juxtaposing your note (styles inside the container vs. outside) and my notes from previous conversations that we should be leveraging focus mod wherever possible, I wonder if that Edit pattern works across all containers?

Question: what is the objective of focus mode?

Is it:

1. Ability to edit the menu items in isolation from any specific Nav block?
2. Ability to edit a specific Navigation block (along with it's items) in a focused editor (i.e. without surrounding blocks getting in the way)?

If it's the later then we should change the approach from what we've done in this PR.

The objective of focus mode in general, and speaking here outside of just its navigation use case, is to let you focus on just the contents of this one template part, or group, or pattern, or piece of content. It's the benefit of the reduced nesting, fewer layers to click through, that just makes it overall a more simple editing experience. And this simpler editing experience can benefit all containers, as noted.

For the navigation, it may be worth connecting dots to #50396 (comment) which features among other things, this mockup:

The user experience is mean to be exactly the same as accessing template parts in the site view. GIF:

That is — you just edit the navigtion in isolation. I understand that @jameskoster's comments are appropriate — the navigation might be collapse to a burger inside a template part, but not if edited directly. I still think the flow is valid.

Does that answer your questions?

...not edit the whole block.

I sense the tension here comes from the fact that you can see the wrapping (Navigation) block in the UI? Template Parts and Reusable Blocks don't show the wrapping block in focus mode. However the Nav block is unique because we need to show the list view sidebar and basic layout.

If we could have "ghost" blocks that are:

• don't display toolbars or show up in list views.
• not serialized

...then we could achieve the same type of thing. Using the Nav block does allow us to ensure that the behaviour is consistent though.

Taking this for a spin, GIF:

Lots of thoughts, not all related to this PR but I'll note which ones probably are.

The fact that the Back button shows the tooltip when it receives focus is incredibly jarring. I'd love for us to remove the tooltip from those buttons entirely. Visually it is clearly a back button, and for screen readers, the aria-label will read aloud.

The ellipsis menu with rename and duplicate are great. It would've been nice if the rename option set focus on the input field, just like the Pages > "Add page" dialog does.

Should that same "Add page" dialog be available in navigation menus, with a plus here, next to the ellipsis?

I would presume to add a page, and add it to the same menu.

Good to fix in this PR: Regardless of plus, we need an Edit icon to edit the particular menu, just like we have an edit button for templates:

The ability to click the preview to edit is a bonus, but for anything that's editable there has to always be the edit button too.

I realize that 3 icon buttons (Add page, edit, ellipsis) might be a lot, but I believe that @jameskoster has some designs that manages to balance that.

This is the main focus mode for editing a navigation:

Good to fix in this PR: We should use the navigation icon in the document title, instead of the layout icon, lest you might think you're editing a template part.

I think the larges open question that exists is the existential one: the navigation you edit here will not always look the same as it will look on your website, because on your website it might be styled locally in the template part or template. I would love for us to think long term on whether it would be possible to reapply some of those styles in this case (style providers, local, global, etc). But I also still think we should land this:

• Having a bespoke navigation section is an incredibly useful way to surface how many navigation menus you have, letting you manage them.
• It isn't clear that the potential visual disconnect is a problem, and making light-weight edits here is still useful.

If we land this and find that it simply doesn't work, we can lean into the Template Parts aspect, where navigation items can be surfaced in the inspector, #51492, and make the Navigation section be more of a "Templates > Manage all templates"-like list view. But it feels too early to make that call. And in the mean time, we can do more to make the discrepancy clear.

Good to fix in this PR: for example we can add help text here:

Instead of the text:

Navigation menus are a curated collection of blocks that allow visitors to get around your site.

We could have:

This is your [Footer] navigation menu. 

You can edit this menu here, but be aware that visual styles might be applied separately in templates or template parts, so the preview shown here can be incomplete.

We can even show a subheading and help-text in the focus-mode canvas just like we do for the Style Book (e.g. Headings, etc).

• we need an Edit icon to edit the particular menu, just like we have an edit button for templates:
• We should use the navigation icon in the document title, instead of the layout icon, lest you might think you're editing a template part.
• We can add help text here:

Instead of the text:

Navigation menus are a curated collection of blocks that allow visitors to get around your site.

We could have:

This is your [Footer] navigation menu. 

You can edit this menu here, but be aware that visual styles might be applied separately in templates or template parts, so the preview shown here can be incomplete.

We can even show a subheading and help-text in the focus-mode canvas just like we do for the Style Book (e.g. Headings, etc).

A couple of small obversations additional to Joen's excellent feedback:

In the edit view, the main Inserter seems to be empty. Searching returns nothing.

I see a "Template" tab which doesn't really make sense. Should this be "Navigation"?

Appreciate this will be a separate discussion, but that tab doesn't seem to have much use here, except for the Revisions link. It almost feels like we could remove the "Block" tab and place its current contents to the "Template" tab. Then you could remove the Navigation block in List View as well, which could be nice as it doesn't seem to serve much purpose here.

I digress. When you enter Revisions for a menu, there is a "← Go to editor" link, which suggests you'll be returned to the edit view on click. But instead it takes you to the menu edit UI in wp-admin. Could this be fixed?

The delete menu modal is different to the one you find when deleting a page. It would be good to align and ideally reuse the same component so we can circle back and update all at once.

There's a small quirk in the drilldown when you only have on menu. Clicking Navigation at the root takes you directly to the menu. But clicking Back then takes you to the Navigation panel which feels a bit disorienting:

Ellipsis icons are mis-aligned:

Ideally the buttons here should match the other sidebar menu items in terms of dimensions etc.

Finally, I noticed that clicking a page takes you to the details panel for that page. It's possible I missed something, but iirc that functionality is going to be removed?

@jameskoster thanks for feedback. Here are the actionable tasls I picked out:

• In the edit view, the main Inserter seems to be empty. Searching returns nothing.
• I see a "Template" tab which doesn't really make sense. Should this be "Navigation"?
• that tab [the one mentioned above] doesn't seem to have much use here, except for the Revisions link. It almost feels like we could remove the "Block" tab and place its current contents to the "Template" tab.
• Remove the Navigation block in List View as well, which could be nice as it doesn't seem to serve much purpose here. If a block is in the canvas we don't currently have a means to hide it from the List View. If this "ghost" Nav block remains as a concept/requirement then it might be worth investing time in creating an API that allows blocks to exist but not show up in the UI. It's beyond the scope of what I can achieve here though.
• When you enter Revisions for a menu, there is a "← Go to editor" link, which suggests you'll be returned to the edit view on click. But instead it takes you to the menu edit UI in wp-admin.
• The delete menu modal is different to the one you find when deleting a page. It would be good to align and ideally reuse the same component so we can circle back and update all at once. That will need to be a separate Issue from this PR.
• There's a small quirk in the drilldown when you only have on menu. Clicking Navigation at the root takes you directly to the menu. But clicking Back then takes you to the Navigation panel which feels a bit disorienting: This is a known issue with the Navigator component. It happens elsewhere as well. It's beyond the scope of what we can tackle here but we do need a separate Issue to address this.
• Ellipsis icons are mis-aligned:
• Clicking a page takes you to the details panel for that page. It's possible I missed something, but iirc that functionality is going to be removed? Won't fix. Being handled in Navigation on Browse Mode: Move the action to the leaf menu #50843

that tab [the one mentioned above] doesn't seem to have much use here, except for the Revisions link. It almost feels like we could remove the "Block" tab and place its current contents to the "Template" tab.

It seems like this comment also applies to Template Parts. Why specifically does this become a problem for Navigation? The reason I ask is that I'm keen to avoid too many branches in the code when there might be underlying problems or concepts that we need to reveal.

I've been looking into why the inserter is empty.

Firstly this is due to the templateLock: 'insert' so we'll need to look into that one.

If we disable that one for testing however, we still get what I assume would be unexpected behaviour, in that when the Nav block is focused opening the inserter does not insert blocks into the Nav block but rather into the "next" slot on the canvas.

I think we need to set the block as the root client id.

Ultimately it ends up with a call to wp.data.select('core/block-editor').getInserterItems(rootClientId). It seems that the rootClientId is not set so our items are not filtered as we'd expect.

It seems like this comment also applies to Template Parts. Why specifically does this become a problem for Navigation?

Template parts also use this region for actions (clearing customisations, deleting), but you're right... the template part inspector is also a bit weak. Probably fine to look into separately.

This is a known issue with the Navigator component. It happens elsewhere as well. It's beyond the scope of what we can tackle here but we do need a separate Issue to address this.

True. Maybe we can tackle this in #51421.

I've been looking into why the inserter is empty.

I noticed the same thing happens when page editing too, and opened #51538. Feel free to edit / expand context there.

I think it's important to note that the issue this block lacking its surrounding context when editing in focus mode is the same issue that we have in the post editor - the post editor cannot know whether the post will be viewed in a single template or an archive template for example, so users will face the same potential confustion.

Followups:
#51580
#51581